無駄な警告を排除する

コードに問題があるときにコンパイラは警告を出しますが、その警告が1本のエッセイぐらいの長さになってしまうことがあります。それを見て密かに「問題があるのはわかったけど、こんなにたくさん警告を出されても、とても対処してる時間がないよ」と思ったことはないでしょうか?対照的に、コンパイル時に出た警告が1つだけのときは、きっと即座に対応ができるでしょう。

新しいプロジェクトをゼロから始めたばかりの時には、まだ問題は多くありません。余分なコードや作りの悪いコードもほとんどなく、警告も出ないでしょう。しかしコードベースが大きくなるにつれて、よくよく注意していないと、問題が増えていくのです。不要なコードや出来の良くないコードが増え、警告もたくさん出るようになってきます。そうした警告の中には、即座に対応を要するわけではない、いわば「ノイズ」のようなものも多いのです。ノイズが数百にも及ぶようになると、その中から本当にすぐ対応しなくてはならないものを見つけるのは困難ですつまり、警告が本来の役割を果たさなくなってしまうのです。

そういう事態を防ぐため、私はビルド時に警告が1つでも出たら、必ずその場でつぶすことにしています。たとえさほど重要でない警告であっても、見過ごすことなく、すぐにつぶすのです。たとえば「ヌルポインタ例外が起きる可能性がある」という警告は、もしかすると重大な警告ではないかもしれません。製品になった時に問題につながるわけではない、たとえ自分ではそれがわかっていても、警告はすぐにつぶすのです。埋め込みドキュメント(Javadocなど)の中に、削除されたパラメータや、名前が変更されたパラメータを参照している箇所があって、そのせいで、警告が出ているというような場合も、ドキュメントを即座に修正します。

出される警告が、どう考えても大した問題にはつながらないものばかりであると判断した場合には、警告ポリシーの変更を検討することもあります。警告ポリシーを変更しでもよいか皆に尋ねるのです。たとえば、メソッドのパラメータや戻り値のドキュメント化ができていない、という警告が出る場合、ドキュメント化にさほどの価値がないと思えば、その警告をやめてもいいでしょう。あるいは、プログラミング言語をアップグレードしたアップグレードした時、Java 5では「ジェネリック型」という概念が導入されましたが、それにより、ジェネリック型パラメータの指定がない古いコードのすべてで警告が出るようになりました。これは(少なくとも、今のところは)あまり意味のない警告でしょう。意味のない警告が出ても、ただ邪魔になるばかりで誰も喜びません。

ビルドで余計な警告が出る度、それを即座につぶすということを続けていれば、「これは意味のある警告か否か」ということを逐一判断する必要がなくなります。不要なものを無視するのも、やはり頭脳労働です。そんな無意味な頭脳労働は、せずに済むようにするのが賢明でしょう。加えて、余計な警告が出ないよう、常にコードを「クリーン」に保っておけば、他の人に仕事を引き継ぐのも簡単です。コードがクリーンになっていなければ、どの警告が重要でどの警告が重要でないかの判断を、引き継いだ人は改めて行わなくてはなりません。あまりに余分な警告が多く出るようだと、意味のある警告も含めてすべて無視する、という行動に出る人もいるでしょう。

本来ビルド中に出る警告は有用なものです。その有用性を実感できるようにするには、ノイズを排除する必要があります。「無用な警告が増えすぎたらその時に対処すればいい」という考え方ではうまくいきません。1つでも無意味な警告が出たら、すぐに対処しましょう。対処には、原因となっているコードを修正する、その警告が目に触れないようにする、警告ポリシーを変更するなどの方法が考えられます。適切に対処しておけば、余分な警告を見ずに済むだけでなく、真に意味のある警告が出た時、それを見逃さずに済みます。ノイズを排除する目的はそこにこそあるのです。